ASIC (Application-Specific Integrated Circuit) design can be divided into front end design and back end design, wherein the front end design personnel output netlist files and timing constraint files according to design requirement documents. A netlist file describes various devices used in chip design and logical connection relationships among the devices, but do not describe how the various devices are physically placed; a timing constraint file is used for specifying the amount of time by which a data signal (and/or a clock signal) needs to arrive in advance or in retard relative to a clock signal (and/or a data signal). Accordingly, time delays of respective circuits in a circuit are prescribed. According to the netlist files and the timing constraint files output by the front end design personnel, the back end design personnel perform layout wiring on netlist level design, which are transformed into layout design composed of standard cells, macrocells and pads, wherein a standard cell library is a library composed of certain basic logical gate circuits, and each cell has same layout height and has a variety of different views; a macrocell comprises a RAM, a ROM and a dedicated IP module; a pad comprises input, output and power supply pad. One important task of the design by the back end design personnel is to satisfy timing constraints required in timing constraint files.
Therefore, timing constraint is one important factor in ASIC design requirement, and a timing constraint conflict means that contradictory timing constraint requirements are made for a same circuit. For example, constraint 1 requires that signal A arrives earlier than signal B, constraint 2 requires that signal A arrives later than signal B, then for signal A, a timing constraint conflict exists. Apparently, if a conflict exists between timing constraints, it is impossible to meet design requirements. However, due to different reasons, the problem of timing constraint conflict exists nearly in all of chip designs.
Currently, in order to detect whether or not timing constraints in timing constraint files can be satisfied, the design personnel usually adopt a STA method (static timing analysis method). Static timing analysis uses indiscriminately a specific timing model, and with respect to a specific circuit, analyzes whether it violates the timing constraints given by a designer. The inputs of a static timing analysis tool are as follows: a netlist, timing constraints and a timing model. A static timing analysis tool implements certain functions to help a user conduct a timing analysis, and main tools in the industry are PrimeTime of Sysnopsys and ETS (Encounter Timing System) of Cadence. During a STA process, in order to detect conflicting timing constraints, there is a need to manually analyze timing report, and debug erroneous timing constraints. However, a timing constraint report of present day ASIC design contains entries varying from 10,000 to 100,000 lines, and debugging work will cost static timing analysis engineers a significant amount of time (several days to several weeks). It will also take ASIC timing-driven layout tools a large amount of time to achieve these goals. If timing constraint conflicts exist in a timing constraint file itself, this design goal is almost impossible. In actual ASIC design, delays in delivery often occur due to this reason. Therefore, if timing constraint conflicts can be acquired in an early stage, design turnaround time in design will be significantly reduced.
Among the existing different STA tools, IBM Einstimer tool provides the following function: if UDT (User Defined Test) and RAT (Required Arrival Time) exist at a same port, a warning message is provided. The function only aims at port and cannot be applied to internal logic, and a warning is given only when the above two tests overlap. If timing constraint of the internal logic conflicts with each other, the tool does not have detecting function. Other STA tools do not even have relevant functions.
Another drawback of the above solution is: for a timing report having 10,000 to 100,000 lines, it is quite difficult to achieve the goal of 100% detecting and covering all the timing constraint conflicts merely by manual work, timing constraint debugging efficiency will be very low.